3rd Generation Partnership Project (3GPP) uses Policy and Charging Control (PCC) functionality to control policy and charging rules in a communication network. FIG. 1, adapted from 3GPP TS 23.203, illustrates PCC functionality in an Evolved 3GPP Packet Switched domain. A Policy Control and Charging Rules Function (PCR) 1 is a functional element that is used for policy control decision and flow based charging control functionalities. The PCRF 1 provides network control regarding service data flow detection, gating, Quality of Service (QoS) and flow based charging (except credit management) towards a Policy and Charging Enforcement Function (PCEF) 2. The PCRF 1 receives session and media related information from an Application Function (AF) 3 and informs AF 3 of traffic plane events.
The PCRF 1 provisions PCC Rules to the PCEF 2 via a Gx reference point and may provision QoS Rules to a Bearer Binding and Event Reporting Function (BBERF) 4 via a Gxx reference point for deployments based on PMIP/DSMIP protocols in the core network.
The PCRF 1 uses PCRF policy decisions to inform the PCEF 2 of PCC rules on the treatment of each service data flow under PCC control. The PCRF 1 communicates with a Subscription Profile Repository (SPR) 5 via a Sp reference point.
The PCEF 2 is responsible for service data flow detection based on filters and definitions included in the PCC rules provisioned by the PCRF 1. The PCEF is also responsible for online and offline charging interactions and policy enforcement. It communicates with an Online Charging System (OCS) 6, which handles service data flow based credit control 7, via a Gy reference point. The PCEF 2 communicates with an Offline Charging System (OFCS) 8 via a Gz reference point. The PCEF 2 is typically located at a gateway 9.
The AF 3 is a functional entity that handles applications in which service is delivered in a different layer (typically the transport layer) from the layer in which the service has been requested (typically the signalling layer). An example of an AF 3 is a Proxy-Call Session Control Function (P-CSCF) in an IP Multimedia Subsystem (IMS) Core Network (CN). The AF 3 communicates with the PCRF 1 via an Rx interface to transfer dynamic session information describing the media to be delivered in the transport layer.
For dynamic services such as Multimedia telephony (MMTeI) and Voice over LTE (VoLTE), the PCRF 1 decides the required quality of the media to be allocated for the media (the media may be, for example, voice, video, instant messaging, picture sharing, white board, and so on). This results in the establishment of dedicated bearer(s) with a guaranteed bit rate (GBR) or non guaranteed bit rate (non GBR), and also affects packet forwarding treatment in the Radio Access Network (RAN) by means of determining a QoS Class Identifier (QCI).
The PCRF 1 determines at the packet core control plane if a bearer to be established and maintained has priority over other bearers for the same or different users. Allocation and retention priority information (ARP) is provided, which contains a level of priority (i.e. how important the bearer is compared to other bearers) and a pre-emption capability and vulnerability (i.e. whether a bearer with lower priority is allowed to be torn down in favour of a bearer with higher priority).
When an AF 3 detects that a user initiates or receives a request to establish a communication session such as a voice call, it may interact with the PCRF 1 to provide service information (e.g. MMTeI service) and Service Data Flows (SDFs). This leads to the provision of the SDFs and the decided QoS information (ARP/QCI) in the PCEF 2. The PCEF 2 determines whether an existing bearer can be used for the SDFs by determining if a bearer already exists with the same ARP/QCI value, or if a new bearer is to be established. If a new bearer is to be established, the value of the ARP reflects how important the new bearer is in relation to other bearers at the packet core network (IP CAN bearers) and the Radio Access Network (RAN).
Turning now to FIG. 2, there is shown a signalling diagram to establish an IMS call between User A 10 and User B 11. User A's 10 home network includes a PCEF 12, a PCRF 13 and an AF 14, and User B′s home network also includes a PCEF 15, a PCRF 16 and an AF 17. The following numbering corresponds to that of FIG. 2:    S1. User A 10 sends a SIP INVITE to the AF 14 to establish a voice call with User B 11. The SIP INVITE includes an SDP offer that indicates a voice call is requested, and includes codecs that User A's terminal can use.    S2-S3. The SIP INVITE is sent to User B 10.    S4-S6. User B 10 is alerted to the SIP INVITE and a SIP 180 is sent to User A 10 to initiate a ringing tone at User A's terminal.    S7-S9. User B 10 answers to accept the communication session. A SIP 200 OK is sent towards User A 10 that includes a SDP answer indicating User B's terminal preferred codecs (selected from those offered by user A) to be used for the audio.    S10-S11. AF 14 requests audio resources for User A 10 and AF 17 requests audio resources for User B 11.    S12-S15. Both AFs 14, 17 establish an AF session for the service by sending an Rx-AAR to the respective Users. The AAR includes an application identifier (e.g. IMS voice), the codecs negotiated by the terminals (taken from the SDP answer) and the flow information (to allow IP traffic and media streaming from User A to User B and from User B to User A).    S16-S21. Both AFs 14, 17 determine the quality of service (QoS) and charging required based on the information received from each AF 14, 17 and the subscription data for the respective Users 10, 11. As a result, the PCC rules containing the allowed SDFs, the associated QoS and the charging information are sent to the respective PCEFs 12, 15.    S22, S23. Dedicated bearers for the voice call with the required QoS are established between PCEF 12 and User A 10, and between PCEF 15 and User B 11. S24. The voice call now proceeds between User A 10 and User B 11.
3GPP Release 9 specifies the provision of emergency services communications in an IMS network. Emergency services are services provided through an emergency Access Point Name (APN) and do not require subscription control. When a PCRF 1 detects that an emergency service session is being established, the session is prioritized in the network by providing a relevant QCI and ARP. According to existing procedures, the PCRF 1 also checks that the emergency connection is not being used in a fraudulent way. This is achieved by checking that the service-URN provided in steps S12 and S13 described above is an emergency service APN.
Where the AF 3 is a P-CSCF, it implements some fraud control mechanisms in order to prevent a user who has initiated an emergency registration from initiating a non-emergency call using that registration. In this case, when the P-CSCF 3 detects that a Request-URI provided by User Equipment (UE) does not match any of the emergency service identifiers stored in the P-CSCF, it will reject the request.
However, it is possible for a fraudulent user to initiate a registration using an emergency APN, but then to use that registration to fraudulently make on-emergency calls, thereby avoiding the usual call charges that a non-emergency call would incur. In this case, when the user initiates a non-emergency call, the P-CSCF 3 fraud procedures do not detect anything abnormal. A mechanism exists whereby, when the P-CSCF 3 contacts the PCRF 1, the PCRF 1 checks whether the APN is an emergency APN. If this is the case and the service that the user tries to use is not an emergency service (Service-URN over Rx does not correspond to an emergency service) the PCRF 1 prevents the user from using the service. In this case the P-CSCF 3 is also expected to reject the request towards the UE. This procedure delegates the control of fraud situations to the packet network domain, instead of in the IMS network, creating unnecessary signalling. Furthermore, the procedure creates an additional processing load at the PCRF 1 since the PCRF 1, which is configured with a list of emergency APNs, must check the APN related to the IP address provided over Rx and check that it corresponds to an emergency APN. This must to be done in all Rx requests for the sole purpose to identify possible faulty UEs in the IMS network.
An alternative procedure that avoids additional processing at the PCRF is to configure a list of IP addresses related to emergency APNs at each P-CSCF. However, this would require extra configuration in all P-CSCFs just to identify fraudulent UEs, which could be a costly and time-consuming exercise, especially when an IP address identifying an emergency APN changes.
Furthermore, the procedure does not prevent a fraudulent user from using SIP messages that never result in an action over the Rx interface. Examples of such messages include SIP SUBSCRIBE request and SIP MESSAGE. In this case the fraudulent user can use the emergency bearer without the P-CSCF 3 detecting that this is a fraudulent use of the emergency bearer. This can lead to an overloaded network and potentially prevent non-fraudulent users from using emergency services.